Certain entities of a telecommunication network are found to be critical entities expected to be fault tolerant since a failure in such entities may cause the overall network failure and a huge amount of subscribers of such network not being able to communicate. In particular, where the telecommunication network is an IP Multimedia Subsystem (hereinafter IMS), a Home Subscriber Server (hereinafter HSS) holding subscriber data for subscribers of the IMS is found to be one of said entities whose failure might make the IMS reach abnormal processing conditions so that a huge amount of subscribers cannot properly make use of services or cannot even make calls. In this respect, most or all failures are accompanied by a reset of the failing entity and a sort of restart once the failure has been solved, likely by reloading permanent stable data if inconsistent data were found to be a reason for the failure. Moreover, not only the prevention of a failure in any critical entity is an issue but also other situations causing the critical entity to become out of service, such as a software or hardware update which cannot enter into operation without producing a restart of the critical entity concerned.
Regarding the abnormal processing conditions that an IMS may reach after a HSS restart, an interested reader has to take into account the different sequence of actions that may take place for a given subscriber immediately after the HSS restart, how such actions are said to be treated in accordance with the 3GPP Technical Specification 23.228 v. 8.0.0, and how such actions concern the HSS. For instance, where a Serving Call Session Control Function (hereinafter S-CSCF) had been assigned at a HSS for serving a given subscriber, namely an original S-CSCF, and such HSS suffers a restart, the given subscriber may still be served by said original S-CSCF; however, the HSS might have lost such information or, at least, have doubts on whether the subscriber is still registered in the original S-CSCF. In this situation, a re-registration from the given user, or a new terminating session from another subscriber belonging to another IMS, may lead the own IMS to select a new S-CSCF in the own IMS for serving the given subscriber, whereas previously established sessions through the original S-CSCF would still be served by said original S-CSCF. In this respect, FIG. 1 and FIG. 2 illustrate some abnormal situations that may occur where a first S-CSCF, namely S-CSCF-1 is presently serving a given subscriber and is thus assigned in a HSS, and said HSS suffers a reset to restart again after having solved a fault situation.
As depicted in FIG. 1, after having a restart in the HSS, temporary data such as S-CSCF identifiers may have been lost in the HSS, and subscriber states may be set to ‘Not Registered’, what means that the S-CSCF-1 assigned to the given user is cleared. In this exemplary situation, the given user tries to register with a new pair of user identities, the so-called IMPI/IMPU pair, which are permanent data under the IMS subscription.
A register message is thus received at an Interrogating Call Session Control Function server (hereinafter I-CSCF) that asks the HSS about a S-CSCF presently serving the given subscriber. In the implementation shown if this exemplary case, any previously assigned S-CSCF, such as the S-CSCF-1 for the given subscriber, has been cleared after the HSS restart. The HSS thus answers the query with capabilities that a selectable new S-CSCF should have for serving the given user. The I-CSCF, taking into account the received capabilities, may select a different S-CSCF to serve the user, which in this exemplary case is S-CSCF-2, where the register message is forwarded. The new selected S-CSCF-2 sends an Authentication Query to the HSS, and the HSS assigns said S-CSCF-2 as presently serving the user by storing a reference to the new S-CSCF-2 for the given user. Then, the HSS downloads authentication information towards the S-CSCF-2. The flow of actions, even though is not drawn in FIG. 1, continues with the currently existing registration procedure.
In the present situation, both HSS and S-CSCF-2 have synchronized data and keep a stable situation. However, the previous S-CSCF-1 assumes to be still the S-CSCF currently serving the user and may be thus acting for sessions previously established and still alive; and this situation may still produce some impacts in further processes since the S-CSCF-1 is keeping out-of-date data for the given user, who is also registered in another server. This may result in a number of subsequent drawbacks derived from having two different S-CSCFs assuming are serving the given user. For example, a Proxy Call Session Control Function server (hereinafter P-CSCF) where the user has accessed the IMS through may have lost any reference to S-CSCF-1, so that still established sessions through the latter cannot be properly released, whereas new originating and terminating sessions will be handled from the S-CSCF-2. Moreover, the problem of having both S-CSCFs simultaneously serving the given user from their own perspective, namely S-CSCF-1 and S-CSCF-2, persists even after a so-called re-registration timer expires in the firstly assigned S-CSCF, S-CSCF-1. Thus, when the timer expires in the S-CSCF-1 and sends an indication of “De-Registration” to HSS, the HSS checks about the S-CSCF which the operation comes from, namely from S-CSCF-1, and since it does not match the presently assigned S-CSCF-2, such de-registration is rejected. In other words, the S-CSCF-1 can not properly de-register the given user. On the other hand, there is no way for the HSS to indicate to the firstly serving S-CSCF-1 that it is not valid anymore since the HSS had cleared all S-CSCF data immediately after, or during, the HSS restart. Also for example, where calls, or sessions, are initiated by an Application Server (hereinafter AS) on behalf of the user, as described in current IMS specifications cited above, the AS may have stored the firstly assigned S-CSCF-1. If the AS had stored the S-CSCF-1 and was subscribed to change notifications, and given that the HSS may have also lost subscription information, HSS can not update the AS with the new assigned server, namely S-CSCF-2, so that the AS continues assuming that the firstly assigned S-CSCF-1 is still serving the user, whilst this S-CSCF-1 does not have the user profile updated, what may lead to an incorrect routing, or even a complete failure, depending on subsequent procedures.
Another exemplary case is depicted in FIG. 2 presenting an abnormal situation that may occur where a first S-CSCF, namely S-CSCF-1, is assigned in a HSS as presently serving a given subscriber, and said HSS suffers a restart. As for the abnormal procedure illustrated in FIG. 1, temporary data may have been lost in the HSS also in this case, such as clearing the previously assigned S-CSCF-1 for a given subscriber and the subscriber state set to ‘Not Registered’ after having the restart in the HSS. In this exemplary situation, another subscriber tries to establish a terminating session towards the given user, and a corresponding invitation is received in the I-CSCF of the terminating network where the given subscriber belongs to.
Then, the I-CSCF interrogates the HSS asking for a S-CSCF currently serving the given subscriber. Since the HSS had a restart and the previously assigned S-CSCF-1 was cleared, the HSS assumes no S-CSCF is presently assigned for serving the subscriber and returns the capabilities that a selectable S-CSCF should have for the I-CSCF to make an appropriate selection. During the process of selecting a S-CSCF fitting the receiving capabilities, the I-CSCF might select a different S-CSCF for serving the subscriber, such as S-CSCF-2 where the I-CSCF forwards the received invitation to establish the terminating session. The S-CSCF-2 confirms to be presently serving the given subscriber towards the HSS, the HSS locally assigns the S-CSCF-2 as presently serving the given subscriber, and downloads subscriber profile information for the given subscriber towards the S-CSCF-2.
The new S-CSCF-2 presently assigned for serving the given subscriber might particularly apply a so-called “user not registered profile” for the session treatment, so that the session might no reach the terminating subscriber, and may terminate at a voice mailbox server, since the given subscriber is supposedly not registered in the IMS.
As for the previous case illustrated in FIG. 1, also this case illustrated in FIG. 2 has some impacts in further processes since the S-CSCF-1 is still keeping out-of-date data for a user registered in another server, namely in the S-CSCF-2. This situation leaves to handle originating and terminating calls, or sessions, in different S-CSCF entities, namely S-CSCF-1 for the originating sessions and S-CSCF-2 for the terminating ones. Moreover, the incorrect or abnormal handling of calls, or sessions, persists even after a new re-registration arrives from the user since the I-CSCF redirects it to the new S-CSCF-2. The problem of having the information in more than one S-CSCF, in S-CSCF-1 and S-CSCF-2, may persist until a re-registration timer expires in the original S-CSCF-1; and then, similar problems as in the previous abnormal case might occur.
On the other hand, when calls are initiated by an AS on behalf of a user, the AS may have stored the previously assigned S-CSCF-1. Generally speaking, where the AS has stored S-CSCF-1 data and was subscribed to changes, and provided that the HSS might have lost subscriber-related information during the restart, the HSS can not update the AS with the new serving node, the S-CSCF-2, so that the assigned S-CSCF is and will still be the previous one, S-CSCF-1, which does not have an up-to-date user profile, thus leading to an incorrect processing.
Nowadays, such failures in telecommunication networks can be prevented, or are at least minimized by having mated entities which may enter into operation to replace a failing entity or an entity to be upgraded, such as a redundant HSS provides for, whereby once the restart has taken place, the redundant HSS updates the restarted HSS with all updated data and then the operation mode is switched back to make the restarted HSS operative whilst the redundant HSS is switched to a non-operating mode.
However, the HSS redundancy is an optional configuration that not all the operators can afford. Therefore, the present invention is aimed to provide a mechanism for recovery of the IMS where an HSS has suffered a restart after a failure, a software upgrade or other reasons.